For packet processing applications running on top of conventional network processors, it is almost mandatory for them to use the underlying hardware facilities to process packets. FIG. 1 illustrates a conventional packet processing system in a network processor. The system includes a packet processing applications (PPA) 107, 108 or 109 executing on network processors 101, 102 or 103, respectively, and interacting with the latter through hardware interfaces 104, 105 or 106, respectively The PPA receives media or GMT packets, process the packets and subsequently transmit (or discard) the processed packet by interacting with the network processor's hardware interfaces. As shown, the network processors 101, 102 and 103 may be different versions of the same basic architecture or a completely different architecture from the same or different manufacturer. Accordingly, the hardware interfaces 104, 105 and 106 provided by the network processors 101, 102 and 103 respectively may be different. When so, different versions of the same PPA, 107, 108 and 109, are required to be developed in order for it to execute on the network processors 101, 102 and 103. Media Packets refer to those packets that arrive through media ports such as Ethernet or ATM ports and are typically processed by the PPA. In the art, they are also termed as Data Packets. GMT (Generic Message Transfer) Packets refers to those packets that serve to control and administer the overall behavior of the PPA. In the art, they are also termed as Control Packets.
However, with this conventional system, the applications directly utilize the specific hardware facilities of the network processor. When an application becomes directly dependent on a specific hardware architecture, it loses its flexibility in function as well as its portability across platforms. The implementation of one application tailored to one platform will inevitably fail on another platform because the other platform uses different mechanisms. Sometimes, the application needs to be changed just because hardware functions are changed without changes in platform.
With the conventional system, customers need to have a comprehensive understanding of the hardware architecture before they can start any implementation or change any of the current solutions. In addition, they need to update their implementations whenever the network processor hardware features are changed. This limits the applicability of their solution and delays their time to market.
Accordingly, there exists a need for a method and apparatus for developing portable packet processing applications on network processors. The method and apparatus should provide flexibility and portability to packet processing across platforms. The present invention addresses such a need.